SoloCodigo

Hola.
Bueno, ya que he tenido que hacer un motor de base de datos, me pregunto, que deveria de tener para que fuera perfecta?
 

manejo de integridad referencial
indexacion binaria
indexacion por mapas de bit
indexacion basada en funciones
control de acceso
administracion de recursos entre sesiones
soporte para pl/sql
soporte para sql
soporte para al menos uno de los lenguajes de punta ( java, .net )
particionamiento
cluster
constraints
jobs
administracion de tablespaces
secuencias
vistas
sinonimos
snapshots
rollback segments
queues
db directories
types
triggers
dblink
perfiles
politicas
sinonimos
mecanismos de recuoperacion
bakups
securitty logs
planes de ejecucion
generacion de estadisticas
planes de ejecucion determinables en tiemop de ejecucion a traves de estadisticas
soporte para transacciones en paralelo
estadisticas detalladas de datos ( histogramas) para determinar planes de ejecucion
optimizer hints
Builtings como utilitarios estandart y no estandart para manejo de cadenas, archivos, generacion de estadisticas, ejecucion de pl/sql sql dinamico, programacion de tareas, salidas por consola etc
Soporte para sentencias DDL y DML
etc
etc
etc.

en resumen, tener como minimo todo lo que tiene una base de datos ORACLE.    

Wow, Juank, gracias por el listado, veo que voy a tener que trabajar mas.

Hola, me llamo mucho la atencion tu post, explicame como asi hiciste un motor de base de datos.
Si puedes facilitarme documentacion seria perfecto y te lo agradeceria y monton.

Atte
Ing_Marco

Lo que he hecho es muy simple y lo tengo que implementar, es tan solo una libreria que crea un archivo para almacenar datos.
Por ahora es muy simple, pero se puede mejorar, esta es la idea:
Se crea un archivo con un encabezado que contiene lo que indica el tipo de archivo, y el numero de bits en el que se encuentran las tablas, es decir:
DB 1:12:2:80...
El prgrama lee sieta cantidad de bits, hasta que el final de la linea sea una nueva (\n)
Despued de la palabra DB hay un espacio o un caractel para saber cundo empiesa la informacion de las tablas, no hay informacion sin tablas, es decir, toda la info esta en tablas.
el numero de la tabla es seguido por dos puntos ( y el numero de bits donde empiesa la tabla, esto lo hago asi, porque no encuentro forma de hacerlo sin que se sature la memoria, es decir, normalmente haria un while para esto usando open, pero uso binmode, seek y read (fopen de stdio en C) y fuera de eso, lo hago asi por que cada tabla estaria compresa con LZW, ya se que todo esto suena muy mal, muy lento, pero realmente no lo es, ya que las funciones de abrir y la informacion de la BD funcionan por separado:
En la libreria, se crea una funcion (todo en OO) que abre la BD y lee la informacion (el archivo se sierra), al momento de guardar o leer un talba/elemento esta nuevamente abre el archivo y lo guarda segun las espesificaciones, realmente la BD nunca es trabajada en memoria.
Tambien doy la opcion de encryptarla con Blowfish...
Lo otro que dice Juank, esta en camino  

solo por curiosidad su -, que estructura de datos estas usando para el manejo de informacion?...guardas todo secuencialmente en archivos binarios o usas una mezcla de arboles (B+, rojinegro...lo que sea) y tablas hash?

salvo tengas en mente un algoritmo nuevo y revolucionario, lo mejor seria que ese tiempo lo inviertieras en hacer perfecta postgress =)

Cita de: "Last Dragon"

salvo tengas en mente un algoritmo nuevo y revolucionario, lo mejor seria que ese tiempo lo inviertieras en hacer perfecta postgress =)

Creo que lo que su- quiere es aprender.    y no hay nada mejor que eso.

Correcto  

-su fantastica idea esa, lo que me cuesta un montón leer tus posts por los cambios que haces en el lenguaje, y lo intento .. me pierdo en ver q quieres decir con la gramatica.
instalate el firefox 2 y directamente te da un link para el diccionario, te subraya en rojo hasta los acentos por ejemplo monton lo tengo subrayado.

Al grano:
-Yo creo q lo fundamental es hacer un gestor en plan cola-cache por un lado que gestione la transacciones y por otro el motor ensi mismo.
Yo hice algo asi con dbase como base de datos q es muy rápida sinceramente. y por otro lado un gestor con la cola.

Revisa el codigo internamente ... de como esta hecho el dbase III, que es facil de conseguir en internet y te explica los separadores y cabeceras que usan te puede dar alguna idea.
Por otro lado no deben ser de longitud fija los registros.
Puedes hacer ficheros separados para cada tabla o no.

Bueno suerte y felicidades por la idea ...


@-su si tuvieras unas notas organizadas donde explicas la estructura y el acceso, asi como las transacciones, sería más facil.(cuando veas el de dbase sabras lo q digo)

Aqui tienes el link que no es el gestor de cola cache que hice para el manejo de dbase(no la publiqué), pero si es una aproximación ya que asi se admite multi acceso y otras opciones(seudo Locking)

Gestionar Dbase desde un programa externo con transacciones (no del tipo SQL, sino tipo DBASE)

@JuanK bueno creo q te pasaste, como en la lista de los reyes magos para la basedatos, no se si es demasiado para -su.

@-su Con que incluya algunas mejoras como q :

• Funcione rápido tanto en lectura como en escritura</li>
• Haga sus copias de seguridad (mirrorring)</li>
• Tenga el cache/gestor y un sistema de indices por arbol básico. </li>
• Acepte SQL en un puerto cualquiera fantástico.</li>

Ya con esto que he dicho y se me queda algo, creo q sería mejor que el mismismo access en cuanto estructura, rapidéz y ahorro de espacio. No hablemos del acceso para redes.
(la verdad q he puesto el liston bajo jejeje,  pero hay q empezar por ahi)

Por seguir avanzando con tu proyecto Una vez tengas una versión estable:
Si te parece bien, me gustaría hacer una pequeña librería para usar tu base de datos para los que usamos Autoit (si funcionara) también valdría para hacer tus páginas dinámicas web tipo php-mysql.

Si necesitas hacer alguna utilidad rápida para la base te lo hago en Autoit.(con tiempo)

Hola -su, es curioso... a mi también me interesa mucho los motores de base de datos, de hecho estoy diseñando (en los tiempos libres) los esquemas y reuniendo ideas para hacer un miniSQL que en esencia tendría todo lo que tiene un SQL pero sin tanta tontería, es decir esos recovecos que casi nadie conoce y cuya utilidad es muy muy limitada y es la que sirve de pie a los fallos de seguridad.

Aparte de eso, pretendo algunas cosas más, lo más esencial es la sencillez de uso, para ello lo implementaré tal como es el español, donde cada parte de la oración gramatical puede casi cambiar de sitio y seguir teniendo el mismo significado, esto evita los errores por falta de ese aprendizaje concienzudo que se requiere para manjar bien las bases de datos.

También quiero proveerlo de sinónimos, es decir porqué usar siempre 'delete' y solo delete ?? .. en el lenguaje normal usamos hasta una veintena de sinónimos, entonces en mi bd 'borrar' 'eliminar' 'destruir' 'tirar' podrán usarse indistintamente, además daré soporte a sinónimos particulares, es decir si uno prefiere emplear el término 'ahorcar' para referirse a 'borrar' podrá hacerlo (de acuerdo a unas sencillas reglas.... aunque la idea del sinónimo libre de usuario va más enfocado a exportarlo a otros idiomas partiendo de una tabla o esquema que se tomaría de un archivo como tabla de traducción... dicho de otro modo que nadie tendrá que aprender el manejo de dicha base de datos en español o inglés, sino en su propio idioma de su país (o en el de su familia si así se quiere y contruye dicha tabla).

La parte más relevante ... el de velocidad lo tengo resuelto, pués he desarrollado el algortimo más eficiente del mundo en cuanto a ordenar listas se refiere, de hecho aun en alto nivel es el doble y más de rápido que cualquiera en escrito en bajo nivel, además sea el nivel de desorden que haya tarda siempre exactamente lo mismo en calcularlo, no hay por tanto ni mejor ni peor caso... ya que soy de lo más pobretón, quiero patentarlo y ver si me deja algún beneficio que me permita vivir un poco dignamente y tapar esos agujeros (si negros, negros.. vamos hacienda o no es negro ?)...

Quería comentarte de paso algo sobre tu esquema.... y ya me dirás:

cuando quieres sacar X dato que no es del primer archivo te toca buscar por cada archivo hasta llegar al que se quiere y eso consume muchos recursos  cuando la base de datos es muy grande.

Mi idea es poner todos los headers al inicio del archivo y asi solo tendria que ir al lugar en el que esta.
El problema es mantener los headers y los datos en el lugar correcto.

Te entiendo, pero yo lo que haría en este caso tuyo es mantener otro archivo sólo para esto, es decir por un lado los datos y por otro las referencias de los datos, es decir la tabla tal empiez en el byte 45678, esos punteros los pondría en otro fichero, y ese otro fichero si que tendría 'headers' para los nombres de las tablas (tal como indicas similar a la estructura xml) y por tanto haciendo su búsqueda en árbol tampoco en modo secuencial...

un esquema un poco rápido sería algo como esto:
esquema para el fichero de cabeceras de la BD
Como puedes ver en este esquema, si se hace bastante completido ya puede ser complejo y profundo, por ello entiendo que es más fácil y mejor tratar independientemente cada aspecto de la base de datos, además esto facilita la concurrencia, me explico:
 Supongamos que tenemos creado esos dos ficheros de los datos de la BD (el de cabeceras con info de la tabla y el de los datos ) de entrada al abrir la base de datos hago DOS copias del fichero de cabeceras, usando el mismo nombre y canbiando la extensión como quiera que aunque una DB sea muy grande, este fichero siempre será bastante más pequeño por tanto esta copia es rápida... bien si ahora hago una solicitud de BUSQUEDA (no delete ni insert : table, ni modificar aspectos de los campos, es decir que no hace variar a este fichero)  mientras se procesa la solicitud buscando en dicho fichero(en una copia), otra consulta puede estar buscando en el fichero de datos, así no es preciso que quede libre el fichero de cabeceras para iniciarse otra query, ya que las querys alternan el uso de una copia u otra según la que no esté en uso, luego el primero que termina de procesar en el fichero de cabeceras 'marca' que ya empieza a usar el fichero de datos, así si mientras la otra query termina si debe esperar, pero al mismo tiempo que se marca que empieza a buscar en el fichero de datos, marca que el fichero de cabecera x ya está libre para otra concurrencia de query, así mientras se valida una query con el fichero de cabeceras, etc... otra consulta está trabajando cen el fichero de datos, luego los tiempos de espera se reducen...

Si en un momento dado la query solicitada es modificar una tabla, eliminarla o crear, implica modificar el fichero de cabeceras, en este caso,  esta query mientras se valida debe esperar a que se marquen libres las 2 copias, estas se eliminan y si aún no está libre el fichero de datos se espera, luego se rematan las acciones en aquella y mientras se hace esto se crean nuevamente esas copias de los ficheros de cabeceras... vamos que una query está en la BD(datos), mientras otras 2 pueden estar en las bd(cabeceras) validando las querys....

Fíjate que con tu sistema de todo en un sólo fichero sólo puedes indicar otro proceso cuando el primero termine totalmente su cometido, es decir hay muchos tiempos de espera, en bases de datos con muchos usuarios...

Y porque usamos las 2 copias y no la original BD(cabecera) ?: porque en ella cada query 'marca' , 'estoy trabajando en la tabla x.y,m si quereis consultar esperad'...claro que marcar esto es mucho más rápido que validar la query y más rápido aún que procesar los datos de la query en la BD(datos).... vamos es un esquema bastante más óptimo, dado que el tuyo queda monousuario.

Naturalmente debe haber un pequeño conjunto de reglas, si voy a alñadir datos a la tabla 'sueldos' y luego voy a hacer la media, pero debo esperar a la consulta saliente deje la bd, la 2ª consulta, pongamos que es más rápido en validarse la query 'hallar la media de la tabla sueldos en el campo medicos' que validar la query 'actualizar la tabla sueldos en los campos medicos, hospital, horario, extrax relacionado con la tabla atrasos_pendientes en los campos medicos, horarios,hospital,extras', en ese caso no puedo enviar a la query 2ª (la que hallaba la media) a la bd, ya que los datos de ésta dependen de la anterior.... una norma básica pués sería: si id_query (a cada query se le da un id, como en las colas del paro, que representa tu 'turno') que ha sido validada (query2 es mayor que la id_query(de la query en proceso de validación, llamémosla query1) y la query 2 trabaja en alguna tabla que la query 1 ha marcado y la query no es consultar datos(leer), sino escribir, entonces query2 debe esperar a que query1 termine...

....me estoy extendiendo...

la idea es mas amplia de lo que crees y tengo en mente unos conceptos nuevos que no deceo que mo los quiten

jejeje.... a mi me pasa lo mismo, pero suele ocurrir 2 cosas casi a igual promedio, que la mitad de esas ideas-conceptos nadie los tiene concebiso, y que por el contrario la mitad de esas ideas-conceptos gran parte tambien lo tiene concebido... normalmente los segundos surgen de los defectos o carencias que te vas encontrando, los primeros surgen de la lucidez cuando trabajs en otro campo y de repente una solución para una cosa extraña te das cuenta que con pocos cambios, o algunos más vale aplicarlo a otro campo, es por ello que resulta difícil que otros estén también en eso mismo, aunque estén en otras cosas que de algún modo compete por ahí pero de manera muy alejada...

ah...una cosa olvídate de las bases de datos en dbse, te recomiendo centrarte en bases de datos relacionales de última generación, aunque cualquier base de datos puede enseñar muchas cosas, las antiguas suelen llevar por el camino, cuyo final es un callejón sin salida, digo sin futuro ... no en vano van siendo abandonadas poco a poco (poco a poco porque de un plumazo no puedes dejar a los usuarios colgados, si no lo harían).

...Entonces retomando el hilo(que me he saltado), el fichero de datos tendría un esquema sin los headers de la tabla, más aún existe la necesidad de tener otro fichero con datos acerca del fichero de datos (no acerca de los datos contenidos, para eso era el fichero de cabeceras de tablas y campos) ni tampoco los datos que en si mismos se valen, sino de otros datos acerca del fichero como cualquier fichero, pero por lo mismo que lo anterior, para evitar problemas de concurrencia, digamos que aunque su escritura es rápida, impide lectura que es donde está el gran tiempo empleado en las querys, por tanto todo proceso que alivie a dicho archivo bienvenido sea... vamos que las piernas han de correr, no pensar , para eso está la cabeza que ella no puede correr...

...y aunque este puede tener algunos esquemas diferentes que pueden merecer su buena lógica, uno de ellos podrías ser algo como:
fichero de control del fichero de datos

Para mi la ventaja de la cachés es clara si se guardan ciertas cachés es más rápido servirlas que procesarlas, aún así puede haber unas reglas de uso,,, el admin de la BD decide si usarlas o no, si el tamaño de una salida de cahcé sobrepasa cierto tamaño queda desechada, el admin determina el tamaño en base a la memoria que dispone su sistema, una repesuesta procesada demasiado simple quizás no suponga excesiva ventaja meterla en caché. No obstante buscar entre 32 registros la coincidencia de una querystring es más rápido que realizarlo en la BD además la salida ya está procesada y además si sale coincidencia con la que exista en caché  la bd está libre para otra previa más tiempo que si esta estuviera en la cola... de todos modos el uso de cachés que sea acertado o no dependerá de como se utilice la bd, no es lo mismo un BD que aloja datos estadísticos de población  que una Bd de compras de como ebay, por poner un ejemplo o igual que una web corporativa de repuestos de automóovil... estás últimas posiblemente tengan poca carga de trabajo y no necesiten cachés y además sus consultas pueden ser muy sencillas limitándose en la mayoría de los casos a verificar si tienen un producto en stock y solicitarlo y consultar si fue enviado o totalizar facturas, etc...

bueno el esquema de los datos creo que ya puedes deducir más o menos como yo lo trazaría por tanto no me extiendo en hacerte algún esquema. Ahora bien si hay cosas en las que quieras profundizar, pués charlemos...

... bueno lo dicho me he estendido...
p.d.: se me olvidaba aclarar que eso del 'ultraHeader' sería para hacer corresponder los 3 ficheros entre si, ya que el motor debería mantener internamente una tabla con las bases de datos registradas en ellas y donde debería mantener campos para esos 3 ficheros, tanto el nombre del archivo como el nombre de la BD para evitar incongruencias, vamos que al abrir una bd el primer intentos es ir a dicha tabla localizar dicho nombre, tomar la ruta, comprobar que en dicha ruta existe ese archivo y que realmente es un archivo de la BD no un archivo cuialquiera renombrado...